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ABSTRACT 


This  report  presents  a revised  version  of  the  Core  Product  Model  (CPM)  initially  reported 
in  [1].  The  initial  CPM  was  intended  to  provide  a base-level  product  model  that  is:  not 
tied  to  any  specific  application  or  software;  open;  non-proprietary;  simple;  generic; 
expandable;  independent  of  any  product  development  process;  and  capable  of  capturing 
all  product  information  shared  throughout  the  product’s  lifecycle.  The  revisions  presented 
continue  to  support  these  intentions. 

The  objectives  of  the  report  are:  (1)  to  document  the  changes  in  the  CPM  relative  to  the 
initial  version;  (2)  to  describe  in  detail  the  revised  CPM,  represented  as  a UML  class 
diagram;  (3)  to  show,  through  Java  and  XML  implementations,  how  the  CPM  can  be 
used  as  the  basis,  or  organizing  principle,  of  a product  information-modeling  framework 
that  can  support  the  full  range  of  product  design  information;  and  (4)  to  present  a rational, 
model-based  process  for  converting  a CPM  supporting  the  early  conceptual  phases  of 
design  into  an  implementation-level  operational  database  support  system. 

UML,  XML  and  Java  representations  of  the  model  are  presented  so  as  to  provide 
interoperability  with  other  models.  A case  study  example  is  discussed  and  its  XML 
representation  is  presented  and  analyzed  to  illustrate  the  principal  elements  of  the  revised 
CPM. 

Keywords 

Product  modeling,  information  modeling,  data  modeling,  artifact,  form,  function, 
behavior,  entity-relationship  data  model,  core  product  model 
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1 Introduction 


1.1  Objectives 

This  report  presents  a revised  version  of  the  Core  Product  Model  (CPM)  initially  reported 
in  [1].  The  objectives  of  the  report  are:  (1)  to  document  the  changes  in  the  CPM  relative 
to  the  first  version;  (2)  to  describe  in  detail  the  revised  CPM,  represented  as  a Universal 
Modeling  Language  (UML)  class  diagram;  (3)  to  show,  throughout  Java  and  extensible 
Markup  Language  (XML)  implementations,  how  the  CPM  can  be  used  as  the  basis,  or 
organizing  principle,  of  a product  information-modeling  framework  that  can  support  the 
full  range  of  product  design  information;  and  (4)  to  present  a rational,  model-based 
process  for  converting  a CPM  supporting  early  conceptual  phases  of  design  into  an 
implementation-level  operational  database  support  system. 

1.2  Historic  background 

As  discussed  in  detail  in  [1],  the  initial  direction  of  the  work  presented  was  an  attempt  to 
provide  a common  basis  among  four  in-house  research  and  development  projects  at 
NIST: 


• the  NIST  Design  Repository  project 

• the  Design-Process  Planning  Integration  project 

• the  Design  for  Tolerancing  of  Electro-Mechanical  Assemblies  project 

• the  Object-Oriented  Distributed  Design  Environment  project. 

As  the  projects  progressed  the  commonality  of  concepts  became  apparent  and  a more 
general  direction  was  sought.  This  direction  was  provided  by  the  perception  of  the  need 
for  new  engineering  design  and  analysis  tools.  Product  development  is  increasingly 
performed  by  geographically  and  temporally  distributed  teams  with  a high  level  of 
outsourcing  of  many  phases  of  the  product  development  process.  New  tools  will  be 
needed  to  address  the  full  spectrum  of  product  development  activities  encompassed  by 
Product  Lifecycle  Management  (PLM)  systems,  rather  than  just  the  narrow  range  covered 
by  traditional  Computer  Aided  Design  and  Engineering  (CAD/CAE)  systems.  Next- 
generation  tools  will  require  representations  that  allow  all  information  used  or  generated 
in  the  various  product  development  activities  to  be  transmitted  to  other  activities  by  way 
of  direct  electronic  interchange.  Furthermore,  product  development  across  companies, 
and  even  within  a single  company,  will  almost  invariably  take  place  within  a 
heterogeneous  software  environment. 

The  Core  Product  Model  was  conceived  as  a representation  for  product  development 
information  which  can  form  the  basis  of  future  systems  that  respond  to  the  demands 
sketched  above  and  provide  for  improved  interoperability  among  software  tools  in  the 
future  [2].  The  model  focuses  on  an  artifact  representation  that  encompasses  a range  of 
engineering  design  concepts  beyond  the  artifact’s  geometry,  including  function,  form, 
behavior  and  material;  as  well  as  physical  and  functional  decompositions,  mappings 
between  function  and  form,  and  various  kinds  of  relationships  among  these  concepts. 
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CPM  follows  the  tradition  of  work  in  the  area  of  artifact  representation.  The  division  of 
artifact  information  into  the  categories  of  form,  function,  and  behavior  has  its  roots  in 
earlier  work  in  intelligent  design  systems.  The  model  is  most  directly  descended  from  the 
representation  developed  as  part  of  the  NIST  Design  Repository  project  [3],  [4].  The 
model  presented  here  shares  both  conceptual  and  representational  aspects  with  that 
developed  by  the  MOKA  (Methodology  and  tools  Oriented  to  Knowledge  based 
engineering  Applications)  Consortium,  an  ESPRIT-funded  collaborative  project  of  the 
European  Union  [5].  The  initial  Core  Product  Model  was  completed  in  the  Fall  of  2000 
and  is  documented  in  [1], 

2 The  revised  Core  Product  Model 

The  Core  Product  Model  is  heavily  influenced  by  the  entity-relationship  data  model  [6]. 
Accordingly,  the  CPM  consists  of  two  sets  of  classes,  called  object  and  relationship.  The 
two  sets  of  classes  are  equivalent  to  the  Unified  Modeling  Language  (UML)  terms  of 
class  and  association  class , respectively  [7]. 

In  the  text  that  follows,  names  of  classes  have  initial  capitalization  (e.  g.,  Information)  and 
names  of  attributes  do  not  (e.  g.,  information). 

A UML  class  diagram  of  the  CPM  is  shown  in  Figure  1. 
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Figure  1:  Class  diagram  of  the  Core  Product  Model 


The  general  characteristics  of  the  classes  are  discussed  first.  Then,  the  semantics  of  each 
class  of  objects  and  relationships  is  presented.  Finally,  the  hierarchies  and  relationships 
' among  the  classes  are  presented. 

2.1  Representation  of  attributes  and  class  types 

In  order  to  make  the  representation  as  robust  as  possible  without  having  to  predefine 
attributes  that  might  be  relevant  only  in  a given  domain,  the  CPM  is  limited  to  attributes 
required  to  capture  generic  product  information  and  to  create  relationships  among  the 
classes.  The  representation  intentionally  excludes  attributes  that  are  domain-specific  (e.g., 
attributes  of  mechanical  or  electronic  devices)  or  object-specific  (e.g.,  attributes  specific 
to  function,  form  or  behavior).  For  the  representation  of  this  information,  two  generic 
information  modeling  concepts  have  been  adopted. 

First,  each  object  and  relationship  has  an  information  attribute.  The  class  Information  is  a 
container  consisting  of: 

• a textual  description  slot; 
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• a textual  documentation  string  (e.g.,  a file  path  or  URL  referencing  more 
substantial  documentation);  and 

• a properties  slot  that  contains  a set  of  attribute-value  pairs  stored  as  strings 
representing  all  domain-  or  object-specific  attributes. 

This  lack  of  specialization  results  in  a small  number  of  broadly  applicable  classes. 

Second,  all  object  and  relationship  classes,  except  for  the  abstract  classes  and  the  utility 
classes  Information,  Processlnformation  and  Rationale,  have  an  attribute  called  type,  the 
value  of  which  is  a string  that  acts  as  a symbolic  classifier1.  Each  object  and  relationship 
class  may  have  a distinct  hierarchical  taxonomy  of  terms  associated  with  that  class.  The 
value  of  the  type  attribute  corresponds  to  one  of  the  terms  within  the  taxonomy  for  the 
given  class.  For  example,  “convert”  is  one  of  numerous  types  of  transfer  functions  and 
the  term  can  serve  as  the  value  of  the  type  attribute  of  an  instance  of  the  class.  Thus,  all 
object  and  relationship  classes  in  the  representation  may  have  their  own  individual 
generic  engineering  classification  hierarchies  that  are  independent  of  any  other  hierarchy 
(eventually,  these  taxonomies  may  be  expanded  into  full  ontologies  of  the  terms  and  their 
semantic  relationships).  Implementations  based  on  the  CPM  may  use  the  type  attributes, 
their  underlying  taxonomies  and  the  attribute-value  pairs  stored  in  the  entities’ 
Information  container  to  provide  the  means  for  model  compilation  of  domain-specific 
specializations  of  the  CPM  classes,  as  discussed  in  Section  4. 

Extensions  and  implementations  of  the  CPM  may  explicitly  assign  attributes  to 
specializations  of  the  CPM  objects  and  relationships.  This  has  been  done,  for  example,  in 
the  Open  Assembly  Model  (OAM)  discussed  in  a companion  report  [9],  so  as  to  provide 
interoperability  with  new  systems,  legacy  data  models  such  as  STEP,  or  existing  CAD 
programs. 

2.2  The  CPM  classes 

The  classes  comprising  the  CPM  are  grouped  below  into  four  categories:  abstract  classes, 
object  classes,  relationship  classes  and  utility  classes. 

2.2.1  Abstract  classes 

In  UML  and  in  object-oriented  programming,  abstract  classes  are  classes  for  which  all 
instances  are  instances  of  a subclass.  Abstract  classes  are  used  in  the  top  of  class 
hierarchies  to  store  common  methods  or  attributes.  Figure  2 shows  the  four  abstract 
classes  in  the  CPM. 

CoreProductModel 

This  class  represents  the  highest  level  of  generalization;  all  CPM  classes  are  specialized 
from  it  according  to  the  class  hierarchy  shown  in  Figure  2 and  further  discussed  in 
Section  2.2.5.  The  common  attributes  type,  name  and  Information  for  all  CPM  classes  are 
defined  for  this  class. 


The  semantics  of  the  term  type  used  in  this  report  differs  from  that  of  the  term  “data  type”  commonly  used  in  computer 
science  data  structure  definitions.  The  use  of  the  term  type  in  this  report  is  consistent  with  the  definition  used  in  the  FRISCO  report: 
“Type  (Synonym:  'Category'):  A type  of  things  is  a specific  characterisation  (e.g.,  a predicate)  applying  to  all  things  of  that  type”  [8] 


9 


CommonCoreObject 

This  is  the  base  class  for  all  the  object  classes.  CommonCoreRelationship  and  its 
specializations,  the  EntityAssociation,  Constraint  Usage  and  Trace  relationships,  may  be 
applied  to  instances  of  classes  derived  from  this  class. 

CommonCoreRelationship 

This  is  the  base  class  from  which  all  association  classes  are  specialized  according  to  the 
class  hierarchy  presented  in  Section  2.2.5.  As  stated  above,  the  CommonCoreRelationship 
class  serves  as  an  association  to  the  CommonCoreObject  class. 


CoreProductModel  \ 


A 


Figure  2:  CPM  abstract  classes 


CoreEntity 

This  is  an  abstract  class  from  which  the  classes  Artifact  and  Feature  are  specialized. 
EntityAssociation  relationships  may  be  applied  to  entities  in  this  class. 

CoreProperty 

This  is  an  abstract  class  from  which  the  classes  Function,  Flow,  Form,  Geometry  and 
Material  are  specialized.  Constraint  relationships  may  be  applied  to  instances  of  this  class. 

2.2.2  Object  classes 

Figure  3 gives  an  abstract  view  of  the  CPM  where  only  object  classes  are  shown.  The 
containment  relationship  subArtifacts/subArtifactOf  is  illustrated  in  the  figure  as  an 
example. 

Artifact 

The  key  object  class  in  the  CPM  is  Artifact.  Artifact  represents  a distinct  entity  in  a 
product,  whether  that  entity  is  a component,  part,  subassembly  or  assembly.  All  the  latter 
entities  can  be  represented  and  interrelated  through  the  subArtifacts/subArtifactOf 
containment  hierarchy  discussed  in  Section  2.2.5.  The  Artifact’s  attributes,  other  than  the 
common  ones  described  in  Section  2.1,  refer  to  the  Specification  that  specifies  the 
Artifact,  the  Form,  Function  and  Behavior  objects  comprising  the  Artifact,  i.e.,  in  UML 
terminology,  forming  an  aggregation  with  the  Artifact,  and  the  Features  that  may 
comprise  the  Artifact. 
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Feature 

A Feature  is  a portion  of  the  artifact’s  form  that  has  some  specific  function  assigned  to  it. 
Thus,  an  artifact  may  have  design  features,  analysis  features,  manufacturing  features,  etc., 
as  determined  by  their  respective  functions.  Feature  has  its  own  containment  hierarchy, 
so  that  compound  features  can  be  created  out  of  other  features  (but  not  artifacts). 


Figure  3:  CPM  object  classes 


Port 

A Port,  a specialization  of  Feature,  is  a specific  kind  of  feature  (sometimes  referred  to  as 
an  interface  feature)  through  which  the  artifact  is  connected  to  (or  interfaces  with)  other 
artifacts.  The  semantics  of  the  term  port  are  deliberately  left  vague:  in  some  contexts 
ports  only  denote  signal,  control  or  display  connection  points,  while  in  other  contexts 
ports  are  equivalents  of  assembly  features  through  which  components  mate. 

Specification 

A Specification  represents  the  collection  of  information  relevant  to  the  design  of  an 
Artifact  deriving  from  customer  needs  and/or  engineering  requirements.  The  Specification 
is  a container  for  the  specific  requirements  that  the  function,  form,  geometry  and  material 
of  the  artifact  must  satisfy. 

Requirement 

A Requirement  is  a specific  element  of  the  specification  of  an  artifact  that  governs  some 
aspect  of  its  function,  form,  geometry  or  material.  Conceptually,  requirements  should 
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only  affect  the  function,  i.e.,  the  intended  behavior,  of  the  artifact;  in  practice,  some 
requirements  tend  to  affect  the  design  solution  directly,  i.e.,  the  form,  geometry  or 
material  of  the  artifact.  Requirements  cannot  apply  to  behavior,  which  is  strictly 
determined  by  the  behavioral  model. 

Function 

A Function  represents  one  aspect  of  what  the  artifact  is  supposed  to  do.  The  artifact 
satisfies  customer  needs  and/or  engineering  requirements  largely  through  its  function. 
The  term  function  is  often  used  synonymously  with  the  term  intended  behavior. 

TransferFunction 

A TransferFunction  is  a specialized  form  of  Function  involving  the  transfer  of  an  input 
flow  into  an  output  flow.  Examples  of  transfer  functions  are  “transmit”  a flow  of  fluid, 
current,  or  messages,  etc.,  or  “convert”  from  one  energy  flow  to  another  or  from  a 
message  to  an  action. 


Flow 

A Flow  is  the  medium  (fluid,  energy,  message  stream,  etc.)  that  serves  as  the  output  of 
one  or  more  transfer  function(s)  and  the  input  of  one  or  more  other  transfer  function(s).  A 
flow  is  also  identified  by  its  source  and  destination  artifacts. 

Behavior 

Behavior  describes  how  the  artifact  implements  its  function.  Behavior  is  governed  by 
engineering  principles  which  are  incorporated  into  a behavioral  or  causal  model. 
Application  of  the  behavioral  model  to  the  artifact  describes  or  simulates  the  artifact’s 
obsei'ved  behavior  based  on  its  form.  The  observed  behavior  can  then  be  examined  with 
respect  to  the  requirements  to  yield  the  evaluated  behavior.  In  the  evaluation  process, 
unintended  behaviors,  i.  e.,  that  do  not  contribute  to  the  intended  function,  can  be 
identified  and  evaluated.  Behavior  has  three  specialized  attributes  or  slots  to  hold  the 
behavioralModel,  the  observedBehavior  and  the  evaluatedBehavior  (typically,  URLs  to 
the  executable  analysis  program  that  embodies  the  behavioral  model,  the  output  of  the 
behavioral  model  and  the  output  of  the  external  evaluation,  respectively). 

Form 

The  Form  of  the  artifact  can  be  viewed  as  the  proposed  design  solution  for  the  design 
problem  specified  by  the  function.  In  the  CPM,  the  artifact’s  physical  characteristics  are 
represented  in  terms  of  its  geometry  and  material  properties.  This  subdivision  was 
introduced  because  some  of  the  intended  applications  tend  to  treat  these  two  aspects  quite 
differently  (e.  g.,  the  product  development  process  may  have  a separate  task  of  material 
selection  for  a given  function  and  geometry). 

Geometry 

Geometry  is  the  spatial  description  of  the  artifact. 

Material 

Material  is  the  description  of  the  internal  composition  of  the  artifact. 

2.2.3  Relationship  classes 
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Relationship  classes  are  derived  from  the  CommonCoreRelationship  class.  They  are 
shown  in  Figure  4.  Relationships  between  object  classes  are  shown  in  Figure  5. 


Figure  4:  CPM  relationship  classes 

Constraint 

A Constraint  is  a specific  shared  property  of  a set  of  entities  that  must  hold  in  all  cases. 
At  the  level  of  the  CPM,  only  the  entity  instances  that  constitute  the  constrained  set  are 
identified.  If  it  is  intended  to  represent  a mathematical  equality  or  inequality  constraint, 
the  properties  slot  of  the  Information  element  associated  with  the  constraint  can  hold  the 
names  of  the  attributes  that  enter  in  the  constraint  as  well  as  the  relational  operator 
linking  them. 


Figure  5:  Relationships  between  object  classes 

EntityAssociation 

EntityAssociation  is  a simple  set  membership  relationship  among  artifacts,  features  and 
ports.  In  applications  of  the  CPM  this  relationship  can  be  specialized;  for  example,  in  the 
Open  Assembly  Model,  EntityAssociation  is  specialized  to  ArtifactAssociation  [9]. 

Usage 

Usage  is  a mapping  from  CommonCoreObject  to  CommonCoreObject.  The  relationship  is 
particularly  useful  when  constraints  apply  to  the  specific  “target”  entity  but  not  to  the 
generic  “source”  entity,  or  when  the  source  entity  resides  in  an  external  catalog  or  design 
repository. 

Trace 
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Trace  is  structurally  identical  to  Usage.  The  relationship  is  particularly  useful  when  the 
“target"  entity  in  the  current  product  description  depends  in  some  way  on  a “source" 
entity  in  another  product  description.  The  type  attribute  of  Trace  specifies  the  nature  of 
the  dependence,  as  follows: 

(a)  Alternative  of.  this  link  points  from  one  alternative  to  another  at  the  highest 
level  of  the  artifact  decomposition  hierarchy  where  the  two  alternatives  differ 
(it  is  assumed  that  multiple  alternatives  may  be  in  the  product  development 
process  simultaneously  and  that  they  respond  to  the  same  set  of  requirements); 

(b)  Versionof  this  link  points  from  one  version  to  another  at  the  highest  level  of 
the  artifact  decomposition  hierarchy  where  two  versions  differ  (it  is  assumed 
that  a new  version  supercedes  a previously  designed  and  approved  version; 
changes  in  requirements  leading  to  the  new  version  can  be  represented  by  the 
same  mechanism,  i.  e.,  as  versions  of  the  original  requirements); 

(c)  Derived J'ronr.  similar  to  Version  of  this  link  allows  family  derivations  to  be 
represented; 

(d)  Is_same_as:  at  any  level  of  the  artifact  decomposition  hierarchy  below  the  one 
where  the  alternative,  version  or  derivative  diverges,  this  link  identifies  a sub- 
artifact of  the  original  artifact  that  this  alternative,  version  or  derivative  is 
identical  to; 

(e)  Is  based  on:  at  any  level  of  the  artifact  decomposition  hierarchy  below  the 
one  where  the  alternative,  version  or  derivative  diverges,  this  link  identifies  a 
sub-artifact  of  the  original  artifact  on  which  the  sub-artifact  of  this  alternative, 
version  or  derivative  is  based,  modified  so  as  to  accommodate  the  new  sub- 
artifacts of  the  alternative,  version  or  derivative. 

2.2.4  Utility  classes 

The  utility  package  of  the  CPM  contains  the  following  three  classes. 

Information 

The  class  Information  is  a container  consisting  of:  (i)  a textual  description  slot;  (ii)  a 
textual  documentation  string  (e.  g.,  a file  path  or  URL  referencing  more  substantial 
documentation);  and  (iii)  a properties  slot  that  contains  a set  of  attribute-value  pairs 
stored  as  strings  representing  all  domain-  or  object-specific  attributes.  Information  is  an 
attribute  of  CoreProductModel  and  all  its  specializations. 

Processlnformation 

The  class  Processlnformation  represents  attributes  related  to  the  product  development 
process,  such  as  state  and  level,  as  used  in  [10],  alternative  and/or  version  designation  or 
other  product  development  process  parameters  that  may  be  used  in  a PLM  environment. 

Processlnformation  is  an  attribute  of  Artifact. 

Rationale 

The  class  Rationale  represents  attributes  that  record  explanatory  information  on  the 
reasons  for  or  justifications  of  a particular  decision  in  the  product  development  process. 
Rationale  is  an  attribute  of  CoreProperty  and  all  its  specializations. 

2.2.5  Class  hierarchies 
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All  object  classes  are  specializations  of  the  abstract  class  CommonCoreObject.  The 
attributes  of  CommonCoreObject  are  linkages  to  the  CommonCoreRelationship,  Usage 
and  Trace  relationships. 

Specializations  of  CommonCoreRelationship  are  the  Constraint,  EntityAssociation,  Usage 
and  Trace  classes. 

2.2.6  Associations  and  aggregations 

First,  all  object  classes,  i.  e.,  specializations  of  the  abstract  class  CommonCoreObject, 
except  Flow,  have  their  own  separate,  independent  decomposition  hierarchies,  also  known 
as  “partOf’  relationships  or  containment  hierarchies-.  Decomposition  hierarchies  are 
represented  by  attributes  such  as  subArtifacts/subArtifactOf  for  the  Artifact  class. 

Second,  there  are  associations  between: 

(a)  a Specification  and  the  Artifact  that  results  from  it 

(b)  a Flow  and  its  source  and  destination  Artifacts  and  its  input  and  output 

Functions 

(c)  an  Artifact  and  its  Features 

Third,  and  most  importantly,  four  aggregations  are  fundamental  to  the  CPM: 

(a)  Function,  Form  and  Behavior  aggregate  into  Artifact 

(b)  Function  and  Form  aggregate  into  Feature 

(c)  Geometry  and  Material  aggregate  into  Form 

(d)  Requirement  aggregates  into  Specification. 

3 Java  and  XML  Implementations  of  CPM 

In  order  to  illustrate  how  the  CPM  can  be  implemented  and  used,  we  have  generated  the 
equivalent  Core  Product  XML  Schema  (CPXS:)  and  a set  of  Java  classes.  We  have  also 
developed  a Java  graphical  user  interface  to  input  product  data  and  generate  XML 
documents  according  to  the  grammar  of  CPXS. 

Appendix  A and  Appendix  A contain,  respectively,  the  Java  classes  and  the  CPXS. 

3.1.1  The  Java  Artifact  class 

As  example  of  the  implementation.  Figure  6 shows  the  Java  Artifact  class.  In  addition  to 
the  attributes  shown  in  the  figure,  the  Artifact  class  is  participating  in  eight  associations 
playing  nine  different  roles,  inherited  from  CoreEntity.  These  roles  are  converted  into 
attributes  of  the  Java  Artifact  class;  these  attributes  are  either  simple  valued  or  multiple 
values  (arrays)  according  to  the  multiplicity  at  the  end  of  the  association.  Furthermore, 
the  inherited  attributes  name,  type  and  information  are  not  shown. 


‘ For  clarity,  only  the  subArtifacts/subArtifact_of  containment  hierarchy  of  Artifact  is  labeled  in  Figures  1 and  3. 
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public  class  Artifact  extends  CoreEntity  { 
public  Specification  satisfies  ; 
public  Feature  hasFeature[]  ; 


public  Artifact  subArtif actOf  ; 
public  Artifact  subArtif acts [ ] ; 

public  Flow  hasInputFlow [ ] ; 

public  Flow  hasOutputFlow [ ] ; 

public  Function  hasFunction [ ] ; 

public  Form  hasForm[]  ; 
public  Behavior  hasBehavior [ ] ; 

public  Processlnf ormation  processlnfo  ; 


Figure  6:  The  Java  Artifact  class 


3.1 .2  The  XML  Artifact  complexType 

The  XML  schema  language  is  not  an  object-oriented  language.  The  XML  schema 
resulting  from  the  conversion  of  an  UML  class  diagram  needs  to  be  constrained  to  ensure 
the  consistency  of  the  XML  instance  document.  Figure  7 shows  the  XML  complexType 
representing  an  Artifact.  Inherited  attributes  are  not  shown  in  this  figure;  the  ListOfxxx 
type  represents  a set  of  strings  referring  to  the  name  subelement  of  elements  of  type  xxx 
(e.g.,  inside  an  artifact,  the  hasFeature  element  contains  a set  of  subelements,  each  of 
which  refers  to  the  name  of  a feature  of  that  artifact). 

As  an  example  of  constraints  for  XML  document  consistency,  consider  the  element  (tag) 
satisfies  inside  the  Artifact  element.  This  tag  references  the  name  or  code  of  the 
Specification  element  that  the  artifact  satisfies;  moreover  the  referenced  Specification 
element  must  be  an  element  of  the  XML  document;  otherwise  the  document  is  not 
consistent. 
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<xsd: complexType  name="Artif act "> 

<xsd : complexContent> 

<xsd : extension  base="CoreEntity"> 

<xsd: sequence> 

<xsd: element  name="hasBehavior " type="ListOf Behaviors " 
minOccurs=" 0 " / > 


<xsd:element  name="hasFunction"  type="ListOf Functions " 
minOccurs=" 0 " / > 


<xsd: element  name^"hasForm"  type="ListOf Forms " minOccurs="0"/> 
<xsd:element  name="satisf ies"  type="xsd : string"  minOccurs=" 1 " /> 
<xsd: element  name="hasFeature"  type="ListOf Features " 
minOccurs=" 0 " / > 

<xsd:element  name="subArtifacts"  type="ListOf Artif acts" 
minOccurs=" 0 " / > 


<xsd : element 
<xsd : element 
<xsd : element 


name="subArtif act Of " 
name=" has Input Flow" 
name="hasOutputFlow" 


type="xsd: string" 
type="ListOf Flows " 
t ype=" Li stOf Flows 


minOccurs=" 

minOccurs=" 


0"/> 

0"/> 


minOccurs=" 0" / > 


</xsd: sequence> 

</xsd : extension> 
</xsd : complexContent> 
</ xsd : complexType> 


Figure  7:  The  XML  Artifact  complexType 

To  ensure  this  consistency,  we  define  the  name  element  to  be  the  key  of  the  specification 
element  (Figure  8)  and  indicate  that  the  element  satisfies  of  the  artifact  element  is  a 
reference  to  this  key.  The  figure  also  shows  that  the  element  containedln  in  requirement 
must  reference  a valid  and  unique  specification  name  (i.  e.,  a key). 

<xsd:key  name="PKSpec"> 

<xsd: selector  xpath="cpm: specification "/> 

<xsd: field  xpath="cpm: name" /> 

</ xsd : key> 

<!--  Elements  that  shall  reference  a specification 
name  --> 

<xsd:keyref  name="specRef " refer="PKSpec"> 

<xsd: selector  xpath="cpm: artifact" /> 

<xsd: field  xpath="cpm: satisfies "/> 

</ xsd : keyref > 

<xsd:keyref  name="speclfRef " refer="PKSpec"> 

<xsd: selector  xpath="cpm : requirement" / > 

<xsd: field  xpath="cpm: containedln "/> 

</ xsd : keyref > 


Figure  8:  Example  of  a consistency  constraint  in  the  XML  artifact  schema 
3.1.3  Example:  XML  representation  of  a planetary  gear 

The  planetary  gear  system  (PGS)  example  considered  in  this  section  was  presented  in 
detail  in  the  Open  Assembly  Model  report  [11],  illustrating  the  representation  of  both 
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containment  hierarchy  and  the  assembly.  Our  interest  in  the  example  here  is  to  show  how 
the  revised  CPM  can  be  used  to  capture  design  information  about  the  product;  thus,  only 
data  important  from  the  design  point  of  view  are  represented. 

Figure  9 shows  the  components  of  the  PGS:  the  main  artifact  is  the  planetary  gear;  it  is 
composed  of  13  subartifacts:  8 screws,  the  output  housing,  the  input  housing,  the  ring 
gear,  the  sun  gear,  and  the  planet  gear  carrier.  Information  such  as  function,  form, 
behavior  and  specification,  related  to  these  subartifacts  are  not  considered  in  this 
example. 


Figure  9:  The  planetary  gear  system 

Figure  10  shows  an  XML  Artifact  element  describing  the  PGS.  The  figure  shows  that  this 
element  includes  the  following  set  of  subelements: 

• information:  a description  and  brief  documentation  of  the  PGS  artifact 

• behaviors:  a list  of  names  of  elements  that  describe  the  behavior  of  the  PGS 
artifact. 

• functions,  forms,  features:  Three  lists  the  elements  of  which  give  the  names  of  the 
function,  “changeSpeedOJRotation‘\  the  from,  “cylindricalFormL\  and  the 
features,  ‘ fasteningHoles , out  pit  t Shaft  Ho  /c“  of  the  PGS. 

• satisfies:  this  is  the  name  of  the  XML  element  that  gives  the  Specification  that  the 
PGS  shall  satisfy.  Appendix  C shows  how  this  specification  is  decomposed  into  a 
set  of  requirements  including:  form,  input  speed,  output  speed,  input  torque  and 
output  torque  requirements. 

• subartifacts:  this  list  gives  the  names  of  subartifacts  of  the  current  PGS  artifact: 
planetGearCarrier,  sunGear,  ringGear,  inputFlousing,  outputHousing  and  eight 
screws. 
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<artif act> 

<name>PlanetaryGearSystem</ name> 

< in format ion> 

<description> 

The  PlanetaryGearSystem  for  changing  speed  rotation 
</description> 
cdocumentation> 

This  is  an  assembly  of  13  different 
subartifacts  and  subassemblies 
</documentation> 

</inf ormation> 

<behaviors> 

<theBehavior  name="pgsBehavior " / > 

</behaviors> 

<f unctions> 

<theFunction  name="changeSpeedOfRotation" /> 

</ f unct ions> 

<f orms> 

<theForm  name= "cyl indr i cal Form" /> 

</ f orms> 

<satisf ies>pgsSpecif ication</ satisfies> 

<f eatures> 

<theFeature  name=" f asteningHoles " /> 

<theFeature  name= " ou tpu t Shaft Hole" /> 

</features> 

<subArtif acts> 


CtheArtif act 

name  = 

" planet Ge a rCarrier"/> 

ctheArtif act 

name  = 

"sunGear"/> 

<theArtif act 

name  = 

"ringGear"/> 

ctheArtif act 

name  = 

" input Housing" /> 

ctheArtif act 

name  = 

"output Housing" / > 

ctheArtifact 

name  = 

"screwl"/> 

ctheArtif act 

name  = 

"screw8 " /> 

</ subArtif acts> 
</artif act> 


Figure  10:  An  XML  element  representing  the  planetary  gear  system 
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Figure  1 1 shows  the  element  named  pgsBehavior.  One  can  see  how  the  properties  slot  of 
the  information  element  is  used  to  capture  important  information  such  as  speed  ratio  and 
output  torque. 

<behavior> 

<name>pgsBehavior</name> 

<inf ormation> 

<description>the  behavior  of  the  planetary  gear 

system  after  assembly  analysis  and  validation 
</description> 

<properties> 

<property  name="speedRatio">3 . 0 : l</property> 

<property  name=" torqueOut ">6 . 78  N . m</property> 
</properties> 

</ inf ormation> 

<artif act>PlanetaryGearSystem</ artifact> 

</behavior> 


Figure  11:  Behavior  element  of  the  planetary  gear  system 

The  complete  XML  instance  document  of  this  example  is  presented  in  Appendix  C, 
where  more  detail  about  the  components,  functions,  forms,  behaviors,  etc.  of  the  PGS 
can  be  found. 


4 Model  compilation  for  the  CPM 

CPM  is  a conceptual  model  intended  for  representing  product  design  information  from  an 
engineer's  point  of  view  and  not  necessarily  for  the  implementation  of  large-scale  Product 
Lifecycle  Management  (PLM)  information  support  systems. 

Specifically,  as  discussed  in  Section  2.1,  CPM  uses  the  special  attributes  type  and 
properties  to  record  user-defined  artifacts,  exemplified  in  the  instance  diagram  of  Figure 
12. 


: Artifact 

s, 

: Information 

type  = "Pin" 

+information 

properties  = "length  5.00  diameter  0.50" 

Figure  12:  CPM  instance  of  attributes 

This  figure  is  an  instance  of  the  class  diagram  shown  in  Figure  13,  showing  an  artifact  of 
type  “pin  that  has  specified  length  and  diameter  attribute  values.  The  values  of  these 
slots  are  delimited  strings  representing  user-defined  subtypes  of  Artifact  and  their 
properties. 
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Figure  13:  CPM  class  diagram  of  attributes 

Such  a representation  will  generally  be  appropriate  and  sufficient  for  the  early  conceptual 
phases  of  design,  where  typically  there  is  a small  number  of  instances  and  few  attributes 
of  interest  for  each  instance.  This  representation  will  not  scale  to  an  implementation 
model,  where  thousands  of  instances  may  occur,  each  with  a long  list  of  application- 
specific  attributes. 

For  application  to  industrial-scale  systems,  the  conceptual  model  of  CPM  must  be 
translated  to  an  implementation  model.  This  is  called  model  compilation  and  is  a part  of 
the  overall  Model-driven  Architecture  (MDA)  defined  by  the  Object  Management  Group 
(OMG)  [12].  MDA  provides  for  translation  of  platform-independent  models  (PIMs), 
such  as  the  CPM,  to  platform-specific  models  (PSMs)  and  for  the  generation  of  efficient 
implementation  languages.  For  example,  the  type/properties  representation  above  is 
inefficient  because  fast  attribute  value  lookup  can  only  be  obtained  with  preparation  at 
compile  time.  If  the  model  compiler  is  able  to  tell  where  each  attribute  will  be  stored  at 
runtime,  it  can  compile  each  access  to  an  attribute  into  retrieval  from  that  predefined 
location,  rather  than  repeating  the  runtime  lookup  at  each  retrieval.  This  requires  user- 
defined  attributes  to  be  translated  to  a compilable  language,  such  as  Java.  Specifically, 
the  model  compiler  creates  subclasses  of  Artifact  from  the  specifications  in  the  type  slot, 
and  defines  attributes  on  the  subclasses.  These  subclasses  could  be  generated  into  a 
UML  repository  [13],  as  a PSM,  then  into  a compilable  language.  This  provides 
flexibility  in  choosing  an  implementation  language.  The  end  result  in  Java,  for  example, 
is  shown  in  Figure  14.3 


class  Artifact 
{ 

Form  form; 

Function  function  ; 

} 

class  Pin  extends  Artifact 
{ 

string  length; 
string  diameter; 

} 

Figure  14:  Java  code  generated  from  an  attribute  instance 

Once  the  code  above  is  compiled,  a design  tool  can  be  used  to  instantiate  the  Pin  class  for 
specific  pin  designs,  such  as  modeled  in  Figure  13,  and  insert  values  into  the  length  and 
diameter  slots.  These  values  can  be  accessed  efficiently  because  the  attribute  locations 


' Other  aspects  of  CPM’s  Information  class  can  be  translated  to  features  on  either  CommonCoreObject  or  Artifact.  For  example, 
documentation  can  be  an  attribute  of  CommonCoreObject,  while  methods  can  be  translated  to  to  operations  on  classes  such  as  Pin. 
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are  compiled.  The  instances  of  the  CPM  used  to  begin  the  compilation  process  can  be 
generated  from  graphical  user  interfaces,  existing  databases  of  designs,  UML 
repositories,  or  whatever  source  has  the  information  required.  The  model  compiler  can 
produce  languages  other  than  Java,  for  example,  DDL  for  relational  databases.  There 
may  be  as  many  attribute-value  implementations  as  there  are  implementations  of  the 
conceptual  model  of  the  CPM,  which  covers  all  of  them  because  it  is  conceptual. 

Another  application  of  model  compilation  in  the  CPM  is  consistency  maintainance  of 
user-defined  attribute  values  of  an  artifact  with  those  of  other  instances  of  the  CPM 
around  it,  such  as  instances  of  Geometry,  Material,  and  so  on.  For  example,  Figure  15 
show  s a UML  model  for  the  Pin  artifact,  with  derivation  of  user-defined  attributes  of  an 
artifact  from  other  instances  of  the  CPM  around  it,  expressed  in  UML's  Object  Constraint 
Language  (OCL)  [14].  This  provides  more  efficient  lookup  of  commonly  used  attribute 
values  directly  from  an  artifact,  rather  than  navigating  through  the  objects  around  it.  The 
generated  code  in  Figure  14  would  include  accessor  operations  that  maintain  consistency 
by  propagating  values  from  instances  of  Geometry,  and  so  on,  to  the  artifact  attributes,  or 
in  the  other  direction,  or  both,  obeying  the  constraints  specified  in  OCL.4 


Pin  : Artifact 

length  = form. geometry. information. property. length 
diameter  = form. geometry. information. property. diameter 
material  = form. material. information. property. materialtype 
breakingStength  = function. information. property. breakingStrength 


Figure  15:  Derivation  path  of  attributes 


Finally,  model  compilation  can  be  used  to  translate  CPM's  delegation-style  of  reusing 
designs  to  the  type/instance  style  of  computational  modeling.  CPM  uses  Artifact  for  the 
representation  of  three  things: 

1 . Description  of  classes  of  physical  objects.  For  example,  the  design  of  a particular 
kind  of  gear  box. 

2.  Use  of  these  descriptions  in  composing  designs  for  other  physical  objects,  for 
example,  the  use  of  a particular  gear  box  design  in  the  description  of  a certain 
model  of  car. 

3.  Descriptions  of  physical  objects  conforming  to  the  designs  above.  For  example, 
maintenance  record  for  an  individual,  physical  gear  box,  with  serial  number  3463, 
installed  in  a particular  car  with  VIN  number  92345645. 

The  use  of  Artifact  for  all  three  reflects  the  engineer's  viewpoint  that  they  represent 
different  stages  in  the  lifecycle  of  the  same  artifact.  These  stages  are  related  by 
associations  in  the  CPM,  such  as  the  Usage  association,  which  relates  stages  1 and  2 
above.  Each  stage  may  have  different  attribute  values  and  even  different  attributes.  For 


4 If  a parameterized  CAD  model  is  available,  an  Artifact  can  refer  to  that  model  and  its  parameter  values,  rather  than  to  the  rest  of 
the  CPM  model. 
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example,  a stage  1 artifact  might  have  an  attribute  for  the  designer's  name,  a stage  2 
artifact  will  describe  its  relations  to  other  artifacts  of  the  design  in  which  is  being 
composed,  and  a stage  3 artifact  might  have  attributes  about  its  date  of  manufacture,  the 
owner,  and  physical  wear  characteristics. 

Computational  models,  on  the  other  hand,  usually  have  distinct  elements  for  each  of  the 
above  stages,  called  type  (or  class),  usage  (or  role),  and  instance : These  reflect  common 
information  system  construction  practices  of  using  program  development  environments 
to  define  the  shapes  of  data  structures  (types,  stage  1 ),  and  monitoring  the  execution  of 
those  programs  in  a separate  debugging  environment  to  find  the  actual  data  stored  in 
those  structures  (instances,  stage  3).  Modem  modeling  techniques  introduce  usages  or 
roles  to  more  reliably  compose  designs  (usages,  stage  2)  [16]. 

Model  compilers  can  bridge  the  engineering  and  computational  viewpoints  by  storing  the 
rules  by  which  the  three  stages  are  distinguished  in  the  engineering  model,  using  these  to 
categorize  artifacts,  and  generate  the  corresponding  computational  models.  For  example, 
in  the  CPM,  an  artifact  that  is  used  by  other,  but  not  used  itself,  is  a stage  1 artifact.  A 
model  compiler  can  use  this  rule  to  determine  which  CPM  artifacts  should  be  translated 
to  types  in  the  computational  models.  Likewise,  a stage  3 artifact  is  one  that  uses  other 
artifacts  that  in  turn  use  other  unused  artifacts.  A model  compiler  can  translate  artifacts 
matching  this  rule  to  instances.  The  complete  rule  set  and  comparison  of  engineering  and 
computational  approaches  will  be  the  topic  of  future  work. 

5 Future  work 

The  revisions  leading  from  the  initial  CPM  [1]  to  the  model  described  above  have  all 
arisen  from  the  experience  gained  in  using  the  CPM  as  the  basis  for  a number  of 
extensions  and  applications,  notably,  the  Design-Analysis  Integration  project  [17]  and  the 
Open  Assembly  Model  project  described  in  [1 1]  and  in  the  companion  report  [9]. 

It  is  anticipated  that  a major  part  of  the  future  work  will  continue  to  involve  (a) 
extensions  and  applications  that  attempt  to  use  the  CPM  as  the  basic  organizing  principle; 
and  (b)  generalizations,  revisions,  modifications  and  extensions  of  the  CPM  proper  in 
light  of  the  experience  gained  from  such  extensions  and  applications.  The  CPM  is  by  no 
means  mature  or  complete,  as  indicated  by  the  need  to  produce  the  present  revised 
version  three  years  after  the  initial  version. 

Future  work  will  also  include  review  of  the  research  literature  on  design  and  product 
modeling,  as  well  as  reviews  of  existing  product  modeling  systems,  aimed  at  identifying 
additional  objects,  relationships  and  shared  attributes  that  may  be  added  to  the  next 
revision  of  CPM.  The  overall  objective  is  to  find  ways  of  extending  the  CPM  so  that  it 
can  eventually  serve  as  the  central  model  for  collecting,  correlating  and  organizing  all 
product  information  throughout  the  entire  product  lifecycle  from  conception  to  disposal. 


' Some  computational  models  use  one  element  as  CPM  does,  but  distinguish  the  three  stages  by  a special  attribute,  for  example, 
MOOD  in  the  Health  Level  7 Reference  Information  Model  [15]. 
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6 Summary  and  conclusions 


The  report  documents  the  revised  version  of  the  Core  Product  Model  initially  presented 
in  [1],  together  with  brief  descriptions  of  two  pilot  implementations  and  some 
preliminary  thoughts  about  the  use  of  a Model-driven  Architecture  for  converting 
conceptual  product  models  based  on  the  CPM  to  robust  implementation  models.  This 
report  is  to  be  viewed  as  a progress  report,  as  it  is  expected  that  experience  with  further 
extensions  and  applications  will  give  rise  to  further  generalizations,  revisions, 
modifications  and  extensions  of  the  CPM  . 
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Appendix  A : Java  implementation  of  the  CPM 

This  is  not  a complete  working  implementation;  the  following  Java  classes  are  provided 
only  to  give  an  idea  of  possible  implementations. 

CPM2  Java  Classes 


package  cpm2  ; 

import  utility . Inf ormation  ; 
import  utility . Process Information; 


public  class 
public 
public 

} 


Transf erFunction  extends  Function  { 
Flow  inputFlow[]  ; 

Flow  outputFlow[]  ; 


public  class  Artifact  extends  CoreEntity  { 
public  Specification  satisfies  ; 
public  Feature  hasFeature [ ] ; 


public  Artifact  subArtif actOf  ; 
public  Artifact  subArtif acts [ ] ; 


public  Flow  hasInputFlow [ ] ; 

public  Flow  hasOutputFlow [ ] ; 


public  Function  hasFunction [ ] ; 

public  Form  hasForm[]  ; 
public  Behavior  hasBehavior [ ] ; 


} 


public  Process  Inf ormation  processlnfo  ; 


public  class  Behavior  extends  CommonCoreOb j ect { 
public  Artifact  behaviorOf Artifact  ; 

} 


public  abstract  class  CommonCoreOb j ect  extends  CoreProductModel  { 
public  CommonCoreRelationship  ccRelation[]  ; 

} 


public  abstract  class  CoreEntity  extends  CommonCoreOb j ect { 
public  EntityAssociation  entityAssociation [ ] ; 

} 


public  abstract  class  CoreProductModel  { 
public  String  type  ; 
public  String  name  ; 
public  Information  information  ; 


public  abstract  class  CoreProperty  extends  CommonCoreOb j ect { 
public  Constraint  constraint [] ; 
public  Requirement  hasRequirement [ ] ; 

} 
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public  class  Feature  extends  CoreEntity 
public  Artifact  artifact; 
public  Feature  subFeatureOf  ; 
public  Feature  subFeatures [ ] ; 


public 

public 

} 

Function  f eatureHasFunction [ ] ; 

Form  f eatureHasForm [ ] ; 

public  class 
public 
public 
public 
public 

} 

Flow  extends  CoreProperty  { 

Artifact  isDestinationOf  ; 

Artifact  isSourceOf  ; 

Transf erFunction  destinationOf 
TransferFunction  sourceOf  ; 

public  class 
public 
public 
public 
public 
public 
public 

} 

Form  extends  CoreProperty  { 

Feature  formOf Feature ; 

Artifact  formOf Artifact  ; 

Form  subForms []  ; 

Form  subFormOf  ; 

Geometry  hasGeometry [ ] ; 

Material  hasMaterial  [ ] ; 

public  class 
public 
public 
public 
public 

} 

Function  extends  CoreProperty  { 

Feature  functionOf Feature  ; 

Artifact  functionOf Artifact  ; 

Function  subFunctions [ ] ; 

Function  subFunctionOf  ; 

public  class 
public 
public 
public 

} 

Geometry  extends  CoreProperty  { 

Form  geometryOf Form; 

Geometry  subGeometries [ ] ; 

Geometry  subGeometryOf  ; 

public  class 
public 
public 
public 

} 

Material  extends  CoreProperty  { 

Form  materialOf Form; 

Material  subMaterials [ ] ; 

Material  subMaterialOf  ; 

public  class 

Port  extends  Feature  { 

public  class 
public 
public 

} 

Requirement  extends  CommonCoreOb j ect { 
Specification  containedln; 

CoreProperty  requiredProperty [ ] ; 

public  class 
public 
public 

Specification  extends  CommonCoreOb j ect { 
Requirement  decomposedlnto [ ] ; 

Artifact  specifies []  ; 

} 


package  utility  ; 


public  class 
public 
public 
public 


Information  { 

String  description  ; 
String  documentation  ; 
String  Properties  ; 


public  class  Processlnf ormation  { 
} 

public  class  Rationale  { 


} 

CPM2  association  classes  converted  into  Java  classes 


public  class  Usage  extends  CommonCoreRelationship  { 
} 


public  abstract  class  CommonCoreRelationship  extends  CoreProductModel  { 
public  CommonCoreOb j ect  associatedCCO [ ] ; 

} 

public  class  Constraint  extends  CommonCoreRelationship  { 
public  CoreProperty  ConstrainedProperty [ ] ; 

} 

public  class  EntityAssociation  extends  CommonCoreRelationship  { 
public  CoreEntity  associatedEntity [ ] ; 

} 


public  class  Trace  extends  CommonCoreRelationship  { 
} 


Appendix  B : CPXS  of  the  Core  Product  XML  Schema 

<?xml  version=" 1 . 0 " encoding="UTF-8 " ?> 

<xsd : schema 

targetNamespace="http : / / namespace . nist . gov/msid/ cpm" 

xml ns : xsd="http : / /www . w3 . org/2001 /XML Schema" 

xmlns : xsi="http : //www . w3 . org/2001 /XMLSchema- instance" 

xml ns : e="http : //namespace .mist . gov/msid/ ext " 

xmlns="http : / / namespace . nist . gov/msid/ cpm" 

xmlns : cpm="http : / /namespace . nist . gov/msid/ cpm" 

elementFormDef ault=" qualified" 

at t r ibu teFormDe fault=" unqualified" > 

<xsd: element  name="model"  type="Model"> 
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< I __  ==================================== 

for  Behavior  the  name  is  a key 
=========================================  --> 

<xsd:key  name=" PKBeh"> 

<xsd: selector  xpath="cpm : behavior" / > 

<xsd: field  xpath="cpm : name" /> 

</ xsd : key> 

<!--  Elements  that  shall  reference  a Behavior  name  --> 
<xsd:keyref  name="behRef " ref er=" PKBeh"> 

<xsd : selector 

xpath=" . /cpm : artifact/ cpm : hasBehavior /cpm : Behavior " /> 
<xsd: field  xpath=" @name" /> 

</xsd : keyref > 


< ! — ==================================== 

for  Requirement  the  name  is  a key 
=========================================  --> 

<xsd:key  name="PKReq"> 

<xsd: selector  xpath="cpm: requirement"/> 

<xsd: field  xpath="cpm:name"/> 

</xsd : key> 

<!--  Elements  that  shall  reference  a Requirement  name  --> 

<xsd: keyref  name="reqRef " refer="PKReq"> 

<xsd : selector 

xpath="cpm: specif i cat ion /cpm : de compos edlnto/ cpm : Requirement" / > 
<xsd: field  xpath=" @name" /> 

</xsd : keyref > 

< ! --  ==================================== 

for  Specification  the  name  is  a key 
=========================================  -_> 

<xsd:key  name="PKSpec"> 

<xsd: selector  xpath="cpm: specif ication" /> 

<xsd: field  xpath="cpm:name"/> 

</xsd : key> 

<!--  Elements  that  shall  reference  a Specification  name  --> 

<xsd: keyref  name=" specRef " ref er="PKSpec"> 

<xsd: selector  xpath="cpm: artifact" /> 

<xsd: field  xpath="cpm: satisfies "/> 

</xsd : keyref > 

<xsd: keyref  name="speclfRef " refer="PKSpec"> 

<xsd: selector  xpath="cpm: requirement " /> 

<xsd: field  xpath="cpm: containedln" /> 

</xsd : keyref > 

< ! — ======================================= 

for  Artifact  the  name  is  a key 
=======================================  --> 

<xsd:key  name="PKArt"> 

<xsd: selector  xpath="cpm: artifact" /> 

<xsd: field  xpath="cpm: name"/> 

</xsd : key> 

<!--  Elements  that  shall  reference  an  Artifact  name  --> 
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<xsd:keyref  name="artlRef " ref er=" PKArt "> 

<xsd: selector  xpath="cpm: function"/> 

<xsd: field  xpath="cpm: functionOf Artifact " /> 
</xsd:keyref> 

<xsd:keyref  name="art2Ref " refer="PKArt"> 

<xsd: selector  xpath="cpm: form"/> 

<xsd: field  xpath="cpm: f ormOf Art i fact "/> 

</ xsd : keyref > 

<xsd:keyref  name="art3Ref " refer="PKArt"> 

<xsd: selector  xpath="cpm: flow"/> 

<xsd: field  xpath="cpm: isSourceOf " /> 

</xsd : keyref > 

<xsd: keyref  name="art4Ref " refer="PKArt"> 

<xsd: selector  xpath=" cpm : f low" /> 

<xsd: field  xpath="cpm: isDestinationOf " /> 

</xsd : keyref > 

<xsd: keyref  name="art5Ref " ref er="PKArt"> 

<xsd : selector  xpath="cpm : feature" / > 

<xsd: field  xpath="cpm: featureOfArtifact"/> 

</ xsd : keyref > 

<xsd: keyref  name="art 6Ref " ref er="PKArt"> 

<xsd: selector  xpath=" cpm: behavior "/> 

<xsd: field  xpath="cpm:behaviorOfArtifact"/> 

</xsd : keyref > 

<xsd: keyref  name="art7Ref " ref er="PKArt"> 

<xsd : selector 

xpath=" . / cpm: specif i cat ion/ cpm: specifies/ cpm: Artifact "/> 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 

<xsd: keyref  name="art8Ref " ref er="PKArt"> 

<xsd: selector  xpath="cpm: artifact "/> 

<xsd: field  xpath="cpm: subArti f actOf " /> 

</xsd : keyref > 

<xsd:  keyref  name="art 9Ref  " ref er=:"PKArt"> 

<xsd : selector 

xpath=" . / cpm: artifact/ cpm: subArti facts /cpm: Artifact "/> 
<xsd: field  xpath=" @name" /> 

</xsd : keyref > 

< ! — ======================================= 

for  Feature  the  name  is  a key 
=======================================  --> 

<xsd:key  name="PKFeat "> 

<xsd: selector  xpath="cpm: feature"/> 

<xsd: field  xpath="cpm: name"/> 

</xsd : key> 

< ! --  Elements  that  shall  reference  a Feature  name  --> 
<xsd: keyref  name=" f eatRef " refer="PKFeat"> 

<xsd: selector  xpath=" cpm : function" /> 

<xsd: field  xpath="cpm: functionOf Feature" /> 

</xsd : keyref > 

<xsd: keyref  name=" f eat2Ref " refer="PKFeat "> 

<xsd: selector  xpath="cpm: form"/> 

<xsd: field  xpath="cpm: formOfFeature"/> 

</xsd : keyref > 

<xsd: keyref  name=" subFeatRef " refer="PKFeat"> 


<xsd: selector  xpath="cpm: feature"/> 

<xsd: field  xpath="cpm: subFeatureOf " /> 

</xsd : keyref > 

<xsd:keyref  name=" f eatNameRef " refer="PKFeat "> 

<xsd: selector  xpath=" . /cpm: feature/ cpm: subFeatures/cpm: Feature "/> 
<xsd: field  xpath=" @name" /> 

</xsd : keyref > 

<xsd: keyref  name=" f eat2NameRef " refer="PKFeat "> 

<xsd: selector  xpath=" . / cpm: art i fact /cpm : has Feature/ cpm: Feature" /> 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 


c I — ==================  ================== 

for  Transf erFunction  the  name  is  a key 
=======================================  --> 

<xsd:key  name="PKTFun"> 

<xsd: selector  xpath="cpm: transf erFunction" /> 

<xsd: field  xpath=" cpm: name" /> 

</xsd : key> 

<!--  Elements  that  shall  reference  a Transf erFunction  name  --> 
<xsd: keyref  name=" tfunOf Ref " refer="PKTFun"> 

<xsd: selector  xpath="cpm: flow"/> 

<xsd: field  xpath="cpm: sourceOf "/> 

</xsd : keyref > 

<xsd: keyref  name=" tfun20fRef " refer="PKTFun"> 

<xsd: selector  xpath="cpm: f low"/> 

<xsd: field  xpath="cpm: destinationOf " /> 

</xsd : keyref > 

< ! — ==================================== 

for  Flow  the  name  is  a key 
========================  ==================  --> 

<xsd:key  name="PKFlow"> 

<xsd: selector  xpath="cpm: f low"/> 

<xsd: field  xpath=" cpm : name" /> 

</xsd : key> 

<!--  Elements  that  shall  reference  a Flow  name  --> 

<xsd: keyref  name=" f lowONameRef " refer="PKFlow"> 

<xsd : selector  xpath=" . / cpm: artifact /cpm: has Input Flow/ cpm: Flow" /> 
<xsd: field  xpath=" @name" /> 

</ xsd : keyref > 

<xsd: keyref  name=" f lowlNameRef " ref er="PKFlow"> 

<xsd : selector  xpath=" . /cpm : art if act /cpm : hasOutputFlow/ cpm: Flow" /> 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 

<xsd: keyref  name=" f low2NameRef " ref er="PKFlow"> 

<xsd : selector 

xpath=" . / cpm: transf erFunction/ cpm: inputFlow/ cpm: Flow"/> 

<xsd: field  xpath="@name"/> 

</ xsd : keyref > 

<xsd: keyref  name=" f low3NameRef " refer="PKFlow"> 

<xsd : selector 

xpath=" . /cpm : transf er Function /cpm : output Flow/ cpm : Flow" /> 
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<xsd: field  xpath="@name"/> 

</xsd : keyref > 

< ! --  ==================================== 

for  Form  the  name  is  a key 

<xsd:key  name="PKForm"> 

<xsd: selector  xpath="cpm: form"/> 

<xsd: field  xpath=" cpm: name"/> 

</xsd : key> 

<!--  Elements  that  shall  reference  a Form  name  --> 

<xsd: keyref  name=" f ormOf Ref " refer="PKForm"> 

<xsd: selector  xpath="cpm: geometry" /> 

<xsd: field  xpath="cpm: geometryOf Form" /> 

</xsd : keyref > 

<xsd: keyref  name=" f romOfRef " refer="PKForm"> 

<xsd: selector  xpath="cpm:material"/> 

<xsd: field  xpath="cpm:materialOfForm"/> 

</xsd : keyref > 

<xsd: keyref  name=" subFromRef " refer="PKForm"> 

<xsd: selector  xpath="cpm: form"/> 

<xsd: field  xpath="cpm: subFormOf "/> 

</xsd : keyref > 

<xsd: keyref  name=" f ormNameRef " refer="PKForm"> 

<xsd: selector  xpath=" . / cpm: form/ cpm: subForms/cpm: Form"/> 

<xsd: field  xpath="@name"/> 

</xsd: keyref> 

<xsd: keyref  name=" f orm2NameRef " ref er="PKForm"> 

<xsd: selector  xpath=" . / cpm : artifact/ cpm : has Form/ cpm : Form" / > 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 

<xsd: keyref  name=" f orm3NameRef " ref er="PKForm"> 

<xsd: selector  xpath=" . / cpm : feature/ cpm : f eatureHasForm/ cpm : Form 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 

< ! --  =======================================- 

for  Geometry  the  name  is  a key 

<xsd:key  name=" PKGeom"> 

<xsd: selector  xpath="cpm: geometry" /> 

<xsd: field  xpath="cpm: name"/> 

</ xsd : key> 

<!--  Elements  that  shall  reference  a Geometry  name  --> 

<xsd: keyref  name="geomRef " ref er=" PKGeom"> 

<xsd: selector  xpath=" . / cpm : form/ cpm : has Geometry /cpm : Geometry" / 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 

<xsd: keyref  name="subGeomRef"  refer="PKGeom"> 

<xsd: selector  xpath="cpm: geometry" /> 

<xsd: field  xpath="cpm: subGeometryOf " /> 

</ xsd : keyref > 

<xsd: keyref  n ame= " ge omN ameRe f " refer="PKGeom"> 


<xsd : selector 

xpath=" . /cpm: geometry/cpm : subGeometries/ cpm: Geometry"/> 

<xsd: field  xpath="@name" /> 

</xsd : keyref > 

< ! — =======================================- 

for  Material  the  name  is  a key 
= = = ===========  = = = ===============.=====  = =-  --> 

<xsd:key  name=" PKMat "> 

<xsd: selector  xpath=" cpm: material "/> 

<xsd: field  xpath="cpm: name"/> 

</ xsd : key> 

<!--  Elements  that  shall  reference  a Material  name  --> 

<xsd: keyref  name="matRef " refer="PKMat"> 

<xsd: selector  xpath="cpm: form/ cpm: hasMaterial/ cpm: Material "/> 

<xsd: field  xpath=" @name" /> 

</xsd : keyref > 

<xsd: keyref  name=" subMatRef " ref er=" PKMat "> 

<xsd: selector  xpath=" cpm: material" /> 

<xsd: field  xpath="cpm: subMaterialOf " /> 

</xsd : keyref > 

<xsd: keyref  name="matNameRef " ref er="PKMat"> 

<xsd : selector 

xpath=" . / cpm: material/ cpm: subMaterials/ cpm : Material " /> 

<xsd: field  xpath="@name" /> 

</xsd : keyref > 

<i — =======================================- 

for  Function  the  name  is  a key 
=======================================  --> 

<xsd:key  name="PKFun"> 

<xsd: selector  xpath="cpm: function"/> 

<xsd: field  xpath=" cpm: name" /> 

</xsd : key> 

<!--  Elements  that  shall  reference  a Function  name  --> 

<xsd: keyref  name^"subFunRef"  refer="PKFun"> 

<xsd: selector  xpath="cpm: function"/> 

<xsd: field  xpath="cpm: subFunctionOf " /> 

</ xsd : keyref > 

<xsd: keyref  name=" f unNameRef " refer="PKFun"> 

<xsd : selector 

xpath=" . / cpm: function/ cpm: subFunctions/ cpm: Function"/> 

<xsd: field  xpath="@name"/> 

</ xsd : keyref > 

<xsd: keyref  name=" f unName2Ref " refer="PKFun"> 

<xsd : selector  xpath=" . /cpm : artifact/ cpm: has Function/ cpm : Function" /> 
<xsd: field  xpath="@name"/> 

</xsd : keyref > 

<xsd: keyref  name=" funName3Ref " refer="PKFun"> 

<xsd : selector 

xpath=" . /cpm: feature /cpm: f eat ureHas Function/ cpm: Function "/> 

<xsd: field  xpath=" @name" /> 

</ xsd : keyref > 

</xsd : element> 
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<!--  This  is  the  main  type  containing  all  other  types  --> 

<xsd : complexType  name="Model "> 

<xsd: sequence> 

<xsd: choice  minOccurs=" 0 " maxOccurs="unbounded"> 

<xsd: element  name="form"  type="Form"/> 

<xsd: element  name="geometry"  type="Geometry" /> 

<xsd: element  name="material " type="Material"/> 

<xsd:element  name=" function"  type="Function"/> 

<xsd : element  name=" transfer Function"  type=" Transfer Function" / > 
<xsd:element  name="flow"  type="Flow"/> 

<xsd:element  name="artif act " type="Artifact"/> 

<xsd:element  name=" feature"  type="Feature" /> 

<xsd:element  name="specif ication"  type="Specif ication" /> 

<xsd: element  name="requirement"  type="Requirement " /> 

<xsd: element  name="behavior " type="Behavior " /> 

</xsd : choice> 

</xsd : sequence> 

</ xsd : complexType> 


< ! --  Core  Product  Model--> 

<xsd : complexType  name="CoreProductModel " abstract=" true"> 

<xsd: sequence> 

<xsd:element  name="type"  type="xsd : string"  minOccurs^" 0 " /> 
<xsd:element  name="name"  type="xsd : string" /> 

<xsd:element  name=" inf ormation"  type=" Inf ormation"  minOccurs=" 0 " /> 
</xsd : sequence> 

</xsd : complexType> 

<!--  Information  --> 

<xsd : complexType  name=" Inf ormation "> 

<xsd: sequence> 

<xsd:element  name="description"  type="xsd : string"  minOccurs=" 0 " /> 
<xsd:element  name="documentation"  type="xsd : string"  minOccurs=" 0 " /> 
<xsd:element  name="properties " type="Properties"  minOccurs=" 0 " /> 
</xsd : sequence> 

</xsd : complexType> 


<xsd: complexType  name="Properties"> 

<xsd: sequence> 

<xsd:element  name="property"  type="Property"  minOccurs=" 1 " 
maxOccurs=" unbounded" / > 

</xsd: sequence> 

</xsd : complexType> 

<xsd: complexType  name="Property"> 

<xsd: simpleContent> 

<xsd : extension  base="xsd : string" > 

<xsd : attribute  name="name"  type="xsd : string"  use=" required" /> 
</xsd:extension> 

</xsd : simpleContent> 

</xsd : complexType> 

< ! -- 


In  the  following  classes  (CommonCoreObject,  CommonCoreRelationship, 
Constraint,  EntityAssociation,  CoreEntity,  CoreProperty,  Requirement) 
some  elements  are  commented.  This  is  to  avoid  errors 
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during  schema  validations,  these  elements  are  of  type  ListOfxx,  xx 
stands  for  an  abstract  class.  As  XML  doesn't  allow  any  instanciations 
of  abstract  classes,  the  commented  elements  can  not  be  used,  but  are 
provided  to  show  how  some  object  oriented  programming  of  the  UML  model 
can  not  be  faithfully  represented  using  XML  schema. 
===================================================================--> 


<!--  CommonCoreOb j ect  --> 

<xsd : complexType  name="CommonCoreOb j ect " abstract="true"> 

<xsd : complexContent> 

<xsd: extension  base="CoreProductModel"> 

<xsd: sequence> 

< ! --<xsd : element  name="commonCoreRelationship" 
type="ListOf CCRelations " minOccurs=" 0 " />--> 

</xsd: sequence> 

</xsd : extension> 

</xsd : complexContent> 

</ xsd : complexType> 

<!--  CommonCoreRelationship  --> 

<xsd : complexType  name=" CommonCoreRelationship"  abstract="true"> 

<xsd: complexContent> 

<xsd : extension  base="CoreProductModel "> 

<xsd: sequence> 

<!--<xsd: element  name="associatedCCOb j ect " type="ListOf CCOb j etcs " 
minOccurs=" 0" />--> 

</xsd: sequence> 

</xsd : extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  Constraint  --> 

<xsd : complexType  name=" Constraint "> 

<xsd : complexContent> 

<xsd: extension  base="CommonCoreRelationship"> 

<xsd : sequence> 

< ! --<xsd : element  name^"constrainedProperty" 
type=" Li stOf CoreProperties " minOccurs=" 0 " />--> 

</xsd : sequence> 

</xsd:extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  EntityAssociation  --> 

<xsd : complexType  name="EntityAssociation"> 

<xsd: complexContent> 

<xsd: extension  base="CommonCoreRelationship"> 

<xsd : sequence> 

< ! --<xsd : element  name="associatedEntity"  type=" Lis tOf CoreEnti ties 
minOccurs^" 0" />--> 

</xsd : sequence> 

</xsd : extension> 

</xsd : complexContent> 

</ xsd : complexType> 

<!--  CoreEntity  --> 

<xsd : complexType  name="CoreEntity"  abstract=" true"> 


35 


<xsd: complexContent> 

<xsd : extension  base="CommonCoreOb j ect "> 

<xsd: sequence> 

< ! --<xsd : element  name="entityAssociation" 
type^"ListOf EntityAssociations " minOccurs=" 0 " />--> 

</xsd: sequence> 

</xsd:extension> 

</xsd : complexContent> 

</xsd: complexType> 

<!--  CoreProperty  --> 

<xsd : complexType  name="CoreProperty"  abstract=" true"> 

<xsd: complexContent> 

<xsd : extension  base="CommonCoreObject"> 

<! — <xsd : element  name^"constraint"  type="ListOf Constraints " 
minOccurs=" 0 " />--> 

<! — <xsd: element  name=" has Requirement"  t ype=" Li stOf Requirements" 
minOccurs=" 0 " />--> 

</xsd : extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  Requirement  --> 

<xsd : complexType  name="Requirement"> 

<xsd: complexContent> 

<xsd: extension  base="CommonCoreOb j ect "> 

<xsd: sequence> 

<xsd:element  name=" containedln"  type="xsd : string"  minOccurs="l"/> 
< ! --<xsd : element  name=" requiredProperty " 
type= " Li stOf Core Properties " minOccurs=" 0 " />--> 

</xsd : sequence> 

</xsd:extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  Specification  --> 

<xsd: complexType  name="Specif ication"> 

<xsd: complexContent> 

<xsd : extension  base="CommonCoreOb j ect "> 

<xsd: sequence> 

<xsd: element  name=" specif ies " 
type="ListOf Artifacts " 

minOccurs-" 0 " /> 

<xsd : element  name="decomposedInto" 
type= "Li stOf Requirements " 

minOccurs=" 0 " /> 

</xsd : sequence> 

</xsd:extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  Behavior  --> 

<xsd : complexType  name= " Behavior "> 

<xsd : complexContent> 

<xsd: extension  base="CommonCoreObject"> 

<xsd: sequence> 
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<xsd: element  name="behaviorOf Artifact " type="xsd : string" 
minOccurs=" 1 " /> 

</xsd: sequence> 

</xsd:extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  Artifact  --> 

<xsd: complexType  name="Artif act"> 

<xsd : complexContent> 

<xsd : extension  base="CoreEntity"> 

<xsd: sequence> 

<xsd: element  name="hasBehavior " type="ListOf Behaviors" 
minOccurs=" 0 " / > 

<xsd:element  name="hasFunction"  type="ListOf Functions" 
minOccurs=" 0 " / > 

<xsd: element  name="hasForm"  type="ListOf Forms" 
minOccurs=" 0 " /> 

<xsd:element  name=" satisfies " type="xsd : string" 
minOccurs=" 1 " /> 

<xsd:element  name="hasFeature"  type="ListOf Features " 
minOccurs=" 0 " /> 

<xsd: element  name="subArtifacts" 
type="ListOf Artifacts " 

minOccurs="0 " /> 

<xsd: element  name="subArtifactOf " type="xsd : string" 
minOccurs=" 0 " /> 

<xsd: element  name="hasInputFlow"  type="ListOf Flows " 
minOccurs=" 0 " /> 

<xsd : element  name="hasOutputFlow" 

type= " Li stOf Flows " 

minOccurs=" 0" /> 

</xsd : sequence> 

</xsd : extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  Feature  --> 

<xsd: complexType  name=" Feature "> 

<xsd : complexContent> 

<xsd : extension  base="CoreEntity"> 

<xsd : sequence> 

<xsd:element  name=" featureOf Artifact " type="xsd : string" 
minOccurs=" 1 " /> 

<xsd : element  name=" f eat ureHas Function"  t ype=" Li stOf Functions" 
minOccur s=" 0 " /> 

<xsd: element  name="featureHasForm"  type="ListOf Forms " 
minOccur s=" 0 " /> 

<xsd:element  name=" subFeatures " type="ListOf Features " 
minOccur s=" 0 " / > 

<xsd: element  name=" subFeatureOf " type="xsd : string"  minOccurs=" 0 " /> 
</xsd : sequence> 

</xsd : extension> 

</xsd : complexContent> 

</ xsd : complexType> 
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<!--  Port  --> 

<xsd : complexType  name="Port"> 

<xsd : complexContent> 

<xsd : extension  base="Feature"> 

</xsd:extension> 

</xsd : complexContent> 

</xsd : complexType> 

< ! --  Form  --> 

<xsd : complexType  name="Form"> 

<xsd : complexContent> 

<xsd : extension  base="CoreProperty"> 

<xsd: sequence> 

<xsd: element  name="hasGeometry"  type="ListOf Geometries " 
minOccurs=" 0 " /> 

<xsd:element  name="hasMaterial " type="ListOfMaterials " 
minOccurs=" 0 " / > 

<xsd:element  name=" subForms " type="ListOf Forms " minOccurs^" 0 " /> 
<xsd:element  name=" subFormOf " type="xsd : string"  minOccurs=" 0 " /> 
<xsd: choice  minOccurs=" 0 " maxOccurs=" 1 "> 

<xsd: element  name=" formOf Artifact " type="xsd : string" 
minOccurs=" 0 " / > 

<xsd:element  name="formOf Feature"  type="xsd : string" 
minOccurs=" 0 " /> 

</xsd : choice> 

</xsd: sequence> 

</xsd : extension> 

</xsd: complexContent> 

</xsd : complexType> 

<!--  Geometry  --> 

<xsd: complexType  name="Geometry"> 

<xsd: complexContent> 

<xsd : extension  base="CoreProperty"> 

<xsd: sequence> 

<xsd: element  name=" subGeometries " type="ListOf Geometries " 
minOccurs=" 0 " /> 

<xsd: element  name="subGeometryOf " type="xsd : string" 
minOccurs=" 0 " /> 

<xsd: element  name="geometryOf Form"  type="xsd : string" 
minOccurs=" 1 " /> 

</xsd : sequence> 

</xsd : extension> 

</xsd : complexContent> 

</ xsd : complexType> 

<!--  Material  --> 

<xsd: complexType  name="Material"> 

<xsd: complexContent> 

<xsd: extension  base^ "Co re Proper ty"> 

<xsd: sequence> 

<xsd: element  name="subMaterials"  type="ListOfMaterials " 
minOccurs=" 0 " / > 

<xsd: element  name=" subMater ialOf " type="xsd : string" 
minOccurs=" 0" /> 

<xsd: element  name="materialOf Form"  type="xsd : string" 
minOccurs^" 1 " /> 
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</xsd : sequence> 

</xsd : extension> 

</xsd: complexContent> 

</xsd: complexType> 

<!--  Function  --> 

<xsd: complexType  name="Function"> 

<xsd : complexContent> 

<xsd: extension  ba se="Co reProperty "> 

<xsd: sequence> 

<xsd:element  name="subFunctions"  type="ListOf Functions" 
minOccurs="0 " / > 

<xsd:element  name="subFunctionOf " type="xsd : string" 
minOccurs=" 0 " /> 

<xsd: choice  minOccurs=" 0 " maxOccurs=" 1 "> 

<xsd:element  name=" functionOf Artifact " type="xsd : string" 
minOccurs=" 0" /> 

<xsd:element  name=" functionOf Feature"  type="xsd : string" 
minOccurs="0" /> 

</ xsd : choice> 

</xsd:sequence> 

</xsd : extension> 

</xsd: complexContent> 

</xsd : complexType> 

<!--  Transf erFunction  --> 

<xsd : complexType  name="TransferFunction"> 

<xsd : complexContent> 

<xsd: extension  base="Function"> 

<xsd: sequence> 

<xsd:element  name=" inputFlow"  type="ListOf Flows " minOccurs=" 0 " /> 
<xsd:element  name="outputFlow"  type="ListOf Flows"  minOccurs=" 0 " /> 
</xsd : sequence> 

</xsd : extension> 

</xsd : complexContent> 

</xsd : complexType> 

< ! --  Flow  --> 

<xsd : complexType  name="Flow"> 

<xsd: complexContent> 

<xsd: extension  base="CoreProperty"> 

<xsd : sequence> 

<xsd:element  name="sourceOf " type="xsd : string"  minOccurs=" 1 " /> 
<xsd: element  name="destinationOf " type="xsd : string" 
minOccurs=" 1 " /> 

<xsd:element  name=" isSourceOf " type="xsd : string"  minOccurs=" 1 " /> 
<xsd:element  name=" isDestinationOf " type="xsd : string" 
minOccurs=" 1 " /> 

</xsd : sequence> 

</xsd:extension> 

</xsd : complexContent> 

</xsd : complexType> 

<!--  ListOfFlows  --> 

<xsd: complexType  name="ListOf Flows "> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd: element  name="Flow"  minOccurs^" 1 " maxOccurs="unbounded"> 
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<xsd: complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use=" required" /> 

</ xsd : complexType> 

</xsd : element> 

</xsd: sequence> 

</xsd : complexType> 

<!--  ListOf Forms  --> 

<xsd: complexType  name="ListOf Forms "> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd:element  name="Form"  minOccurs^" 1 " maxOccurs="unbounded"> 

<xsd : complexType> 

<xsd : attribute  name="name"  type="xsd: NCName"  use="required" /> 

</ xsd : complexType> 

</xsd : element> 

</xsd : sequence> 

</xsd : complexType> 

<!--  ListOf Geometries  --> 

<xsd : complexType  name= "ListOf Geometries "> 

<xsd : sequence  minOccurs="l"> 

<xsd:element  name="Geometry"  minOccurs=" 1 " maxOccurs="unbounded"> 
<xsd : complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use="required" /> 

</ xsd : complexType> 

</xsd : element> 

</xsd: sequence> 

</ xsd : complexType> 

<!--  ListOfMater ials  --> 

<xsd : complexType  name= "ListOfMater ials "> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd:element  name="Material " minOccurs=" 1 " maxOccurs="unbounded"> 
<xsd: complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use="required"/> 
</xsd : complexType> 

</xsd : element> 

</xsd : sequence> 

</xsd: complexType> 

<!--  ListOf Functions  --> 

<xsd: complexType  name="ListOf Functions "> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd: element  name="Function"  minOccurs=" 1 " maxOccurs="unbounded"> 
<xsd : complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use=" required" /> 
</xsd : complexType> 

</xsd : element> 

</xsd: sequence> 

</xsd : complexType> 

<!--  ListOf Behaviors  --> 

<xsd : complexType  name=" ListOf Behaviors "> 

<xsd : sequence  minOccurs="l"> 

<xsd:element  name="Behavior"  minOccurs=" 1 " maxOccurs="unbounded"> 
<xsd : complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use="required" /> 
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</xsd : complexType> 

</xsd : element> 

</xsd:sequence> 

</xsd : complexType> 

<!--  ListOf Features  --> 

<xsd : complexType  name=" ListOf Features "> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd: element  name="Feature"  minOccurs=" 1 " maxOccurs="unbounded"> 

<xsd : complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use="required"/> 
</xsd: complexType> 

</xsd : element> 

</xsd: sequence> 

</xsd : complexType> 

<!--  ListOf Artifacts  --> 

<xsd : complexType  name=" ListOf Artifacts "> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd:element  name="Artif act " minOccurs=" 1 " maxOccurs="unbounded"> 
<xsd : complexType> 

<xsd : attribute  name="name"  type="xsd : NCName"  use="required" /> 

</xsd : complexType> 

</xsd : element> 

</ xsd : sequence> 

</xsd : complexType> 

<!--  ListOf Requirements  --> 

<xsd: complexType  name="ListOfRequirements"> 

<xsd : sequence  minOccurs=" 1 "> 

<xsd:element  name="Requirement " minOccurs=" 1 " maxOccurs="unbounded"> 
<xsd : complexType> 

<xsd : attribute  name^"name"  type="xsd: NCName"  use="required" /> 

</xsd : complexType> 

</xsd : element> 

</xsd : sequence> 

</ xsd : complexType> 

<!--  Processlnf ormation  --> 

<xsd: complexType  name= "Process Information "> 

<xsd: sequence> 

</xsd : sequence> 

</xsd : complexType> 

<!--  Rational  --> 

<xsd: complexType  name="Rational"> 

<xsd: sequence> 

</xsd : sequence> 

</xsd : complexType> 

< ! --  Trace  --> 

<xsd : complexType  name="Trace"> 

<xsd : complexContent> 

<xsd : extension  base="CommonCoreRelationship" > 

</xsd : extension> 

</xsd : complexContent> 

</ xsd : complexType> 
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<!--  Usage  --> 

<xsd : complexType  name="Usage"> 

<xsd: complexContent> 

<xsd : extension  base="CommonCoreRelationship"> 
</xsd : extension> 

</xsd : complexContent> 

</xsd : complexType > 


</xsd: schema> 

Appendix  C : XML  representation  of  a planetary  gear 

<?xml  version=" 1 . 0 " encoding="UTF-8 " ?> 

<model  xmlns="http : / / namespace . nist . gov/msid/ cpm"> 

<!--  Artifact  --> 

<artif act> 

<name>PlanetaryGearSystem</ name> 

<inf ormation> 

<description>The  PlanetaryGearSystem  for  changing  speed 
rotation 

</description> 

documentation>This  is  an  assembly  of  13  different 
subartifacts  and  subassemblies 

</ documentation> 

</inf ormation> 

<hasBehavior> 

<Behavior  name="pgsBehavior"/> 

</hasBehavior> 

<hasFunction> 

< Function  name=" change SpeedOf Rotation" / > 

</hasFunction> 

<hasForm> 

<Form  name="cylindricalForm"/> 

</hasForm> 

<satisf ies>pgs Specif ication</ satis f ies> 

<hasFeature> 

<Feature  name=" f asteningHoles " /> 

<Feature  name=" output Shaft Hole" / > 

< /has Feat ure> 

<subArtif acts> 


<Artif act 

name 

= 

"planetGearCarrier"/> 

<Artif act 

name 

= 

"sunGear"/> 

<Artif act 

name 

= 

"ringGear"/> 

<Artif act 

name 

= 

" input Housing" / > 

<Artif act 

name 

= 

" output Hous ing" /> 

<Artif act 

name 

= 

" screwl " /> 

<Artif act 

name 

= 

" screw2 "/> 

<Artifact 

name 

= 

" screw3 " /> 

<Artif act 

name 

= 

" screw4 "/> 

<Artif act 

name 

= 

" screw5 "/> 

<Artif act 

name 

= 

" screw6" / > 

<Artif act 

name 

= 

" screw7 "/> 

<Artif act 

name 

= 

" screw8 "/> 
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</ subArtif acts> 

</ artif act> 

<!--  Features  --> 

<f eature> 

<name>f asteningHolesc/ name> 

<inf ormation> 

<description>8  holes  to  contain  screws</description> 
<documentation>4  holes  are  in  the  output  housing  side, 
the  other  4 are  in  the  input  housing  side.  They  are 
used  to  fasten  the  output  housing  and  the  input 
housing  to  the  ring  gear. 

</ documentation> 

</ information> 

<f eatureOf Artif act>Plane tar yGearSystem</ f eatureOf Artif act> 
</ feature> 

<f eature> 

<name>outputShaf tHole</ name> 

<inf ormation> 

<description>the  cylindrical  stem  of  the  output  shaft 
will  be  inserted  into  this  hole</description> 

</ information> 

<f eatureOf Artif act >Plane tar yGearSystemc/ f eatureOf Artif act> 
<f eatureHasFunction> 

< Function  name=" stemlnsertion" / > 

</ f eatureHasFunction> 

</feature> 

<!--  subartifacts:  These  artifacts  are  incomlete . Their 
specifications , 

behaviors,  functions,  forms  are  TBD  --> 

<artif act> 

<name>planetGearCarrier</ name> 

<sat is fies>pgs Specif ication</ satisfies> 

<subArtif actOf >PlanetaryGearSystem</ subArtif actOf > 

</ artif act> 

<artif act> 

<name>sunGear</name> 

<satisf ies>pgsSpecif ication</satisf ies> 

<subArtif actOf >Plane tar yGearSystem</ subArtif actOf > 

</ artif act> 

<artif act> 

<name>ringGear</ name> 

<satisf ies>pgsSpecif ication</ satis fies> 

<subArt if actOf >Plane tar yGearSystem</ subArtif actOf > 

</ artif act> 

<artif act> 

<name>inputHousing</ name> 

<satisf ies>pgsSpecif ication</ satis fies> 

< subArtif actOf >PlanetaryGearSystem</ subArtif actOf > 

</ artif act> 

<artif act> 

<name>outputHousing</name> 

<satisf ies>pgs Specif icationc/ satisfies> 

<subArtif actOf >PlanetaryGear SystemC/ subArtif actOf > 

</artif act> 

<artif act> 
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<name>screwl</ name> 

<satisf ies>pgs Specif ication</ satisfies> 

<subArtif actOf >PlanetaryGearSystem</ subArtif actOf > 
</ artif act> 

<artif act> 

<name>screw2</name> 

<satisf ies>pgs Specif ication</ satisfies> 

<subArt if actOf >Plane tar yGearSystem</ subArtif actOf > 
</ artif act> 

<artif act> 

<name>screw3</name> 

<satisf ies>pgs Specif ication</ satisfies> 

<subArt if actOf >Plane tar yGearSystem</ subArtif actOf > 
</artif act> 

<artif act> 

<name>screw4</name> 

<satisf ies>pgs Specif i cat ion</ satisfies> 

<subArt if actOf >Plane tar yGearSystem</ subArtif actOf > 
</ artif act> 

<artif act> 

<name>screw5</name> 

<satisf ies>pgs Specif icationc/ satisfies> 

< subArtif actOf >PlanetaryGearSystem</ subArtif actOf > 
</ artif act> 

<artif act> 

<name>screw6</name> 

<satisf ies>pgs Specif ication</ satisfies> 

<subArtif actOf >Plane tar yGearSystemc/ subArtif actOf > 
</artif act> 

<artif act> 

<name>screw7</ name> 

<satisf ies>pgs Specif ication</ satisfies> 

< subArtif actOf >PlanetaryGearSystem</ subArtif actOf > 
</ artif act> 

<artif act> 

<name>screw8</ name> 

<satisf ies>pgsSpecifi cation< /satis fies> 

<subArtif actOf >Plane tar yGearSystem</ subArtif actOf > 
</ artif act> 


< ! --  Functions  --> 

<function> 

<name>changeSpeedOf Rotation</name> 

< in format ion> 

<description>this  the  main  function  of  the 
PI anetaryGear System . 

it  provides  adequate  and  variabel  speed  for  all 

possible 


operations 

</description> 

<properties> 

<property 

<property 

<property 

<property 

<property 

<property 


name=" input ">rotational  energy</property> 
name= " output ">rot at ional  energy</property> 
name="speedln">l 800rpm</property> 
name="speedOut ">TBD< /proper ty> 
name=" torqueIn">2 . 26  N . m</property> 
name=" tor queOut ">TBD< /proper ty> 
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</properties> 

</ inf ormation> 

<f unctionOf Art if act>PlanetaryGearSystem</f unctionOf Art if act> 

</ function> 

<function> 

<name>stemInsertion</ name> 

<f unctionOf Feat ure>output Shaft Ho le</ f unctionOf Feature> 

</ function> 

<!--  Specifications  — > 

< spec if ication> 

<name>pgs Specif ication</name> 

<specif ies> 

<Artif act  name= " Planetar yGear Sys t em" /> 

</ specif ies> 

<decomposedInto> 

<Requi remen t name=" f ormSpecif i cat ion" / > 

<Requirement  name=" input Speed" /> 

<Requirement  name= "output Speed" /> 

<Requirement  name=" input Torque" / > 

<Requi remen t name^" output Torque" / > 

</decomposedInto> 

</ specif ication> 

<!--  Requirements  --> 

< requi remen t> 

<name>inputSpeed</name> 

< informat ion> 

<description>input  speed  shall  be  between  900  and  1800  rpm 
</ description> 

</ inf ormation> 

<containedIn>pgs Specif ication</containedIn> 

</ requi remen t> 

<requirement> 

<name>outputSpeed</ name> 

< in format ion> 

<description>output  speed  shall  be  between  300  and  600  rpm 
</description> 

</ information> 

<containedIn>pgsSpecif ication</ containedIn> 

</ requirement> 

<requirement> 

<name>inputTorque</ name> 

<inf ormation> 

<description>input  torque  shall  be  around  2.26 
N . m</description> 

</ in format ion> 

<containedIn>pgs Specif ication</ containedIn> 

</ requirement> 

<requirement> 

<name>outputTorque</ name> 

<inf ormation> 

<description>output  torque  shall  be  around  6.78 
N . m</ description> 

</ information> 

<containedIn>pgs Specif ication</ containedIn> 

</ requi remen t> 


45 


than 


< requirement 

<name>formSpecif ication</name> 

<inf ormation> 

<description>length  less  than  100mm,  width  and  height  less 

60mm,  weight  less  that  150g 
</description> 

</inf ormation> 

<containedIn>pgs Specif ication</containedIn> 

</ requirement> 

<!--  Form  --> 

<f orm> 

<name>cylindricalForm</ name> 

< in format ion> 

<description>the  form  of  the  PlanetaryGearSystem 
shall  be  cylindrical 
</description> 

<documentation>length  less  than  100mm,  width  and  height 

less 

than  60mm,  weight  less  that  150g.  No  more  details 

about 

the  geometry  of  this  form  are  available 
</documentation> 

</ information> 

<f ormOf Art if act>PlanetaryGearSystem</ f ormOf Art if act> 

</ f orm> 

<!--  Behavior  --> 

<behavior> 

<name>pgsBehavior</name> 

< in format ion> 

<description>the  behavior  of  the  the  planetary  gear 
system  after  assembly  analysis  and  validation 
</description> 

<properties> 

<property  name=" speedRatio">3 . 0 : l</property> 
<property  name=" torqueOut">6 . 78  N . m</property> 
</properties> 

</inf ormation> 

<behaviorOf Art if act>PlanetaryGearSystem</behaviorOf Art if act> 
</behavior> 

</model> 
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